System testing infrastructure for analyzing and preventing soft failure in active environment

ABSTRACT

A method for testing a system under test (SUT) in an active environment includes receiving, by a testing system, a code path of the SUT that causes a soft failure in the active environment. The soft failure occurs in the active environment during execution of the SUT based at least on a parameter of the active environment. The method further includes generating, by the testing system, multiple tests for testing the SUT, the tests generated based on a coverage model of the SUT, wherein the coverage model uses several attributes. The method further includes selecting, by the testing system, from the generated tests, a set of tests that are associated with the code path. The method further includes executing, by the testing system, only the set of tests that are selected on the SUT to analyze a cause of the soft failure.

BACKGROUND

The present invention relates to testing of a computer program and, morespecifically, testing environmental conditions in a system on which thecomputer program is being executed to detect, analyze, and prevent asoft failure in the environmental conditions.

Computerized devices control almost every aspect of our life—fromwriting documents to controlling traffic lights. However, computerizeddevices are often error-prone, and thus require a testing phase in whichthe errors should be discovered. The testing phase is considered one ofthe most difficult tasks in designing a computerized device. The cost ofnot discovering an error may be enormous, as the consequences of theerror may be disastrous. Coverage tools for checking software provide ameasure of how well the software being evaluated has been exercisedduring testing and thereby give a level of assurance that the softwareis of high quality.

SUMMARY

According to one or more embodiments of the present invention, a methodfor testing a system under test (SUT) in an active environment includesreceiving, by a testing system, a code path of the SUT that causes asoft failure in the active environment. The soft failure occurs in theactive environment during execution of the SUT based at least on aparameter of the active environment. The method further includesgenerating, by the testing system, multiple tests for testing the SUT,the tests generated based on a coverage model of the SUT, wherein thecoverage model uses several attributes. The method further includesselecting, by the testing system, from the generated tests, a set oftests that are associated with the code path. The method furtherincludes executing, by the testing system, only the set of tests thatare selected on the SUT to analyze a cause of the soft failure.

According to one or more embodiments of the present invention, a systemincludes a system under test (SUT) that is being executed in an activeenvironment, and a testing system that performs a method for testing asystem under test (SUT) in an active environment. The method includesreceiving, by a testing system, a code path of the SUT that causes asoft failure in the active environment. The soft failure occurs in theactive environment during execution of the SUT based at least on aparameter of the active environment. The method further includesgenerating, by the testing system, multiple tests for testing the SUT,the tests generated based on a coverage model of the SUT, wherein thecoverage model uses several attributes. The method further includesselecting, by the testing system, from the generated tests, a set oftests that are associated with the code path. The method furtherincludes executing, by the testing system, only the set of tests thatare selected on the SUT to analyze a cause of the soft failure.

According to one or more embodiments of the present invention, acomputer program product includes a computer-readable storage mediumhaving computer-executable instructions stored thereupon, which whenexecuted by a processor cause the processor to perform a method fortesting a system under test (SUT) in an active environment. The methodincludes receiving, by a testing system, a code path of the SUT thatcauses a soft failure in the active environment. The soft failure occursin the active environment during execution of the SUT based at least ona parameter of the active environment. The method further includesgenerating, by the testing system, multiple tests for testing the SUT,the tests generated based on a coverage model of the SUT, wherein thecoverage model uses several attributes. The method further includesselecting, by the testing system, from the generated tests, a set oftests that are associated with the code path. The method furtherincludes executing, by the testing system, only the set of tests thatare selected on the SUT to analyze a cause of the soft failure.

Additional technical features and benefits are realized through thetechniques of the present invention. Embodiments and aspects of theinvention are described in detail herein and are considered a part ofthe claimed subject matter. For a better understanding, refer to thedetailed description and to the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The specifics of the exclusive rights described herein are particularlypointed out and distinctly claimed in the claims at the conclusion ofthe specification. The foregoing and other features and advantages ofthe embodiments of the invention are apparent from the followingdetailed description taken in conjunction with the accompanying drawingsin which:

FIG. 1 shows a schematic illustration of a computerized environment inaccordance with one or more embodiments of the present invention;

FIG. 2 is a block diagram representing modules providing a testinginfrastructure according to an embodiment of the invention;

FIG. 3 shows a flowchart of a method for reducing test cases byeliminating redundant tests, in accordance with one or more embodimentsof the present invention;

FIG. 4 depicts a flowchart of a method for generating a minimal set oftests for diagnosing portions of a system that are causing soft failureswhen executing a system under test according to one or more embodimentsof the present invention;

FIG. 5 depicts a flowchart of a method for executing the minimal set oftests for the system under test to detect soft failures, according toone or more embodiments of the present invention;

FIG. 6 depicts a flowchart of a method for exercising a specific portionof a system under test according to one or more embodiments of thepresent invention; and

FIG. 7 depicts a computer system that may be used in one or moreembodiments of the present invention.

The diagrams depicted herein are illustrative. There can be manyvariations to the diagrams or the operations described therein withoutdeparting from the spirit of the invention. For instance, the actionscan be performed in a differing order or actions can be added, deletedor modified. Also, the term “coupled” and variations thereof describehaving a communications path between two elements and do not imply adirect connection between the elements with no interveningelements/connections between them. All of these variations areconsidered a part of the specification.

DETAILED DESCRIPTION

When testing a system (i.e., a system under test (SUT)), it is observedthat some errors (also referred to herein as “bugs”) are not surfacedconsistently due to a requirement of specific environmental or timingcircumstances. For example, in the case of a software SUT, thecircumstances can include one or more parameters of a computer system onwhich the software is being executed. For example, the parameters caninclude settings of the computer system, other software being executedon the computer system, a hardware configuration of the computer system,and the like. In a similar manner, in the case of a hardware SUT, theconfiguration of a system of which the hardware SUT is a part of canaffect the environmental conditions. In other words, particular errorsin the SUT can be a result of the system state and not the quality ofthe SUT itself. Such errors are sometimes referred to as “softfailures.” Identifying such conditions that can lead to soft failures isa technical challenge. Additionally, identifying the soft failures,i.e., determining that an error is a soft failure can also be atechnical challenge.

Embodiments of the present invention address such technical challenges.According to one or more embodiments of the present invention, a minimalset of test cases for a SUT are executed on the system. It should benoted that the system is different than the SUT; the SUT is beingexecuted using the system. The minimal set of test cases can begenerated using combinatorics test designing (CTD). Errors can beidentified based on a subset of tests that fail from that minimal set.Further, according to one or more embodiments of the present invention,inverse CTD is used to localize the fault in the system.

According to one or more embodiments of the present invention, CTD isperformed with respect to an interaction requirement, such as apair-wise interaction, n-tuple interaction, or any other. The test planmay provide for sufficient coverage tasks that assure that theinteraction requirement is fulfilled. In some exemplary embodiments,test planning is based on a modeling of the test space using afunctional coverage model. The test space can represent inputs,scenarios, configurations, the application's internal state, or anyother aspect that might need to be tested. The functional coverage modelmay include a set of functional attributes. In other embodiments of thepresent invention, the coverage model can include one from a number oftypes of coverage known in the art, such as statement coverage, linecoverage, condition coverage, path coverage, method coverage, and thelike. The type of coverage does not affect identifying the softfailures.

Further, with respect to test planning, a test-space may definepotential tests that may be executed on the SUT. A test can beassociated with exactly one potential test, as opposed to coveragetasks. In some exemplary embodiments of the present invention, severaldifferent tests may hold the same potential test.

In some exemplary embodiments of the present invention, the motivationfor the approach of CTD is that most bugs depend on the interactionbetween a small number of functional attributes. CTD algorithms may alsodeal with scalability issues. The CTD algorithms may assume that thecombinations space is too large to be represented explicitly, and theyuse various techniques to try to generate an optimized test plan withoutexplicitly enumerating all possible combinations. Examples of suchalgorithms may be a reduction to the orthogonal arrays or covering arrayproblems. Those techniques are limited in the type of restrictions theyallow on the value combinations, or in the type of requested interactionlevel, and still hit scalability issues as the number of model variablesincreases.

Despite these reduction efforts, once the SUT has been implemented, newfeatures are typically requested and added as users exercise thefunctionality of the system. New test cases are created as the newfeatures are added. Sets of test cases are, therefore, maintained forthe SUT to ensure that previous functionality still works, that newfunctionality works and that the new functionality does not adverselyaffect the old functionality. These test case sets are termed regressiontest cases, and the activity of testing the SUT to ensure conformancewith legacy requirements is typically termed regression testing.

Generally, at least some of the regression test case sets are createdand maintained manually over the life of the SUT. They are manuallyselected based on the number of tests that can be run in an allottedamount of time, tests that exercise the most important features of theSUT, and tests that have historically exposed the greatest number ofproblems in the SUT when introducing new features, or other suchreasons. A drawback of conventional regression testing is that some ofthe additional test cases repeat test actions that are covered by othertest cases in the regression test case set. This is the penaltyassociated with the incremental addition of test cases. For a large,complex project, using the manual iterative method of adding test casesto the regression test case set can result in a large amount ofduplicate test actions. Such technical challenges are also addressed bythe technical solutions facilitated by embodiments of the presentinvention.

The technical challenges arise because without the ability toautomatically regenerate the test set in response to changes made to therequirements, the testing effort proceeds inefficiently. Initially, itis possible to manually select a test set that is close to the optimalset of test cases from a small requirements model. The requirementsmodel, however, grows as new features and capabilities are added to theSUT. Once the requirement model is large, manually selecting a close toan optimal set of test cases is technically challenging, if notimpossible. In one known method, the original set of test cases isaugmented with test cases that exercise the new parts of therequirements model. Over time, using this approach, there will beextensive redundancy between the test cases. The same scenarios orscenario fragments are included in a large proportion of the test cases.Other scenarios and scenario fragments will be ignored entirely and willnot be included in any test case. Overall, there will be a large numberof test cases, far more than necessary for coverage, and the coverageachieved by this large test set will be poor. Thus, a further technicalchallenge is to reduce this redundancy by removing test cases that coveridentical execution paths. As described further, embodiments of thepresent invention address such technical challenges.

Referring now to FIG. 1 , showing a schematic illustration of acomputerized environment in accordance with embodiments of the presentinvention. A computerized environment 100 may include one or morecomputerized tools. It should be noted that the depiction is onepossible example of a block diagram and that some components may not bedepicted for clarity.

In one or more embodiments of the present invention, a user 110, such asa developer, a QA staff member, a tester, a designer, a verificationengineer or the like, may interact with the computerized environment100. The user 110 may utilize a Man-Machine Interface (MMI) 112 such asa terminal, a display, a keyboard, an input device or the like.

In some exemplary embodiments of the present invention, a coverage modeldefining tool 102 may be utilized to define the test coverage model,such as a functional coverage model, or the like. In some exemplaryembodiments of the present invention, the user 110 may define theattributes that are to be tested, for example, the functional attributesin case a functional coverage is being tested. In some exemplaryembodiments of the present invention, a similar tool may be utilized todefine a test-space. In some exemplary embodiments, the coverage modelmay be adapted to be utilized as a test model.

In some exemplary embodiments of the present invention, a test executionengine 108 may be utilized to test the SUT. It will be noted that theSUT may be hardware, firmware, software, combination thereof, or anyother type of computerized device. The test execution engine 108 may bea simulation-based verification tool, a test-generation platform, or thelike. The test execution engine 108 may be operatively coupled to a testplanning tool 106 and configured to perform testing in accordance withthe test plan. In some exemplary embodiments, the test planning tool 106may provide the tests for the test execution engine 108 to perform. Itwill be noted that dynamic verification is a broader concept thantesting the SUT, and it further includes test planning, coverageanalysis and the like. The test execution engine 108 provides only oneaspect of the entire scope of operations that may be performed duringdynamic verification and should not be used to construe the term“dynamic verification” narrowly.

In some exemplary embodiments of the present invention, a coverageanalysis tool 104 is configured to measure coverage of the test spacefor the SUT based on the dynamic verification performed by the testexecution engine 108. For example, the coverage analysis tool 104 can bea functional coverage analysis tool. The coverage analysis tool 104provides a coverage measurement, such as a portion of the coveragetest-space or of the defined test plan, indicative of coverage tasksthat were covered during dynamic verification performed by the testexecution engine 108. The user 110 may review the coverage measurementand/or the list of covered tasks.

In some exemplary embodiments of the present invention, a test planningtool 106 may define a test plan to be covered. In some exemplaryembodiments of the present invention, the test plan may be a set ofcoverage tasks to be covered. In some exemplary embodiments of thepresent invention, the test plan tool 106 may provide tests that arelikely to cover the test plan, such as based on a test benchmark storedin a datastore which includes tests that are known/estimated to coverspecific aspects of the SUT. As another example, the test plan tool 106is configured to generate tests so as to cover coverage tasks. The user110 may review the test plan, the selected test or the like. In someexemplary embodiments of the present invention, the user 110 may provideparameters for the test planning tool 106 to use in determining theobjective of the test plan, such as a desired interaction level.Embodiments of the present invention enable the elimination of anyredundancy in the generated tests.

While the depiction in FIG. 1 has been described with specificcomponents including the coverage model defining tool 102, coverageanalysis tool 104, test planning tool 106 and the test execution engine108, embodiments of the present invention are not limited to thesecomponents or system configurations and can be implemented with othersystem configuration employing fewer or additional components.

FIG. 2 is a block diagram representing modules providing a testinginfrastructure according to an embodiment of the invention. Morespecifically, the infrastructure includes a test generator 208. The testgenerator 208 accesses a test infrastructure, such as a repository oftest cases 202, which stores suites of test cases available to verifythe correctness of the SUT 214. Each test case specifies an input to beapplied to the SUT 214 and the expected response that should be returnedin response to this input (to indicate its correct operation).Typically, the test cases are organized into sets (test suites), forexample, each test suite for a different component of the SUT 214.

The test generator 208 creates an execution bucket for each run of thetest on the SUT 214. The bucket specifies the operations to be performedfor running the desired test cases in a machine-readable language (suchas XML-based). Particularly, in the case of a complete test, all theavailable test cases are executed on each component of the SUT 214;conversely, in the case of a regression test, the execution is limitedto a subset of selected test cases. The bucket so obtained can be savedinto a file.

A test execution engine 108 controls the execution of the bucket readfrom the file. For each test case of the bucket, this involves theapplication of the corresponding input to the SUT 214. In responsethereto, the SUT 214 returns a corresponding output to the testexecution engine 108. The test execution engine 108 determines theresult of the test case by comparing its output with the correspondingexpected response (extracted from the file, for example). The result ofthe test case (i.e., positive when the two values match and negativeotherwise) is saved into a log. For example, this may be achieved bymeans of a standard Test Tracking Tool (TTT). The results of the(current) run of the test are available in the log for their analysis.

For a large, complex SUT 214, the test case infrastructure 202 cancontain a large amount of duplicate test actions/test cases. Inaccordance with certain embodiments of the present invention, onetechnique developed to address these challenges incorporates the use ofa fingerprint repository 206 with a store of information including a setof fingerprints that correspond to a plurality of regression testsstored in the test repository 202. In one embodiment, the fingerprintsare generated by a fingerprint generator 204. For instance, thefingerprint repository 206 can include fingerprints of most, if not all,of the tests stored in the test repository 202 and a reference to wherecopies of the test are located throughout the test infrastructure,similar to an index in a book. Each fingerprint uniquely identifies aspecific code path covered by a corresponding test case. In this manner,the system can identify fingerprints (and corresponding tests) that areredundant, and in some cases duplicate.

According to embodiments of the present invention, processing of theresults 216 of the regression tests generated by the test generator 208and executed by the test execution engine 108 may include determinationof a code path traversed during execution of each generated regressiontest and generation of a fingerprint for each executed regression testbased at least in part on the code path. In some embodiments of thepresent invention, these steps may be performed by the fingerprintgenerator 204.

A test case analyzer 218 analyzes the test cases 202 to identifyparticular traits in the test cases 202. The test case analyzer 218 canselect and/or deselect particular test cases 202 for execution. Theselection can be based on one or more factors, such as, redundancy,bypassing testing of particular portion of the SUT, bypassing testing ofparticular attributes, etc.

For example, to determine if any of the test cases 202 can be bypassed,the test case analyzer 218 compares fingerprints, source code of thetest cases 202, the attribute-value pairs being used by the test cases202, or any other such factors to identify redundancy. For example, thefingerprints corresponding to all test cases generated by the testgenerator 208 to a plurality of fingerprints stored in the fingerprintrepository 206. The test case analyzer 218 provides a list of theregression test cases generated by the test generator 208 that havematching fingerprints with one or more fingerprints stored in thefingerprint repository 206, i.e., redundant test cases. This informationis used to select and discard the duplicate test cases from the testrepository 202 (as described below). Alternatively, or in addition, thetest case analyzer 218 compares the code in the test cases 202 todetermine test cases 202 that have similar source code, and hence, thattest similar portions of the SUT. Alternatively, or in addition, thetest analyzer 218 compares the attribute-value pairs being used by thetest cases 202. The test cases 202 that compare the same attribute-valuepairs may be reduced in one or more embodiments of the presentinvention. In other embodiments of the present invention other factorscan be used to identify redundancy. Comparison/matching of suchinformation can be performed using known techniques, such as textcomparison, code comparison, semantic analysis, etc.

In one or more embodiments of the present invention, the test caseanalyzer 218 identifies the most disjoint set of test cases 202 to coverthe edges of the test space before (or after) narrowing in on thefault(s) in the environment 100. A minimal set of tests (describedfurther herein) is such a disjoint set of tests to identify edge casesduring execution of the SUT, which helps diagnose soft failure(s) in thetesting environment (rather than a fault in the SUT itself).

FIG. 3 shows a flowchart of a method 300 for reducing test cases byeliminating redundant tests, in accordance with embodiments of thepresent invention. It should be noted that each operation of the method300 depicted in FIG. 3 can be performed by one or more of the modules orthe like depicted in FIG. 1 , or FIG. 2 , whose operation will bedescribed in more detail hereinafter. These program modules may beimplemented in any combination of hardware, software, and/or firmware.In certain example embodiments of the present invention, one or more ofthese program modules may be implemented, at least in part, as softwareand/or firmware modules that include computer-executable instructionsthat when executed by a processing circuit cause one or more operationsto be performed. A system or device described herein as being configuredto implement example embodiments of the present invention may includeone or more processing circuits, each of which may include one or moreprocessing units or nodes. Computer-executable instructions may includecomputer-executable program code that when executed by a processing unitmay cause input data contained in or referenced by thecomputer-executable program code to be accessed and processed to yieldoutput data.

At block 302, the fingerprint generator 204 may generate fingerprintsfor each respective test that has been run on the SUT 214. Thefingerprint generator 204 may retrieve the preexisting regression testsfrom one or more datastores, such as test repository 202. In exampleembodiments of the present invention, these preexisting regression testsmay have been executed on source code, which may also be retrieved fromthe test repository 202. In example embodiments of the presentinvention, inputs to the source code to be tested may be modeled as acollection of attribute-value pairs. As such, in certain exampleembodiments, each regression test case may be a test case to test theoperation of the source code of the SUT 214 with respect to a particularcombination of attribute values. In example embodiments of the presentinvention, the fingerprint generator 204 may generate fingerprints foreach executed regression test based at least in part on the code pathtraversed by the source code covered by the corresponding test case.

At block 304, the test generator 208 may generate one or more tests(e.g., a set of regression tests) to run on the SUT 214. In oneembodiment, the test generator 208 may utilize CTD to determine a set oftests to be executed. In one embodiment, the test generator 208 may begiven a description of a test space in the form of variables, theirrespective values, and possibly restrictions on the values combinations.In one exemplary embodiment, the test generator 208 may select a subsetof the possible tests that ensures coverage of all valid combinations ofevery two attributes (or every three, or four, etc.). Many tools andalgorithms exist for CTD such as those disclosed in Grindal, M., Offutt,J., Andler, S. F. “Combination testing strategies: a survey”. Softw.Test, Verif. Reliab 15(3), 167-199 (2005), and the disclosed embodimentmay utilize any of one of them.

In one or more embodiments of the present invention, the test generationmay be performed by selecting a subset of the tests that would maintain100% n-wise coverage with respect to the tested test space, andtherefore maintaining the n-wise coverage metric with respect to thevalid test space. In some exemplary embodiments of the presentinvention, at block 304, the coverage analysis tool 104 may be operativeto determine a subset of the possible combinations of values. The subsetof the possible combinations of values is with respect to the coveredtest space defined by the coverage model determined by the coveragemodel defining tool 102. The most common criterion for test selection iscode coverage, i.e., select a subset of the tests that cover code thathas recently changed, for example. As noted earlier, the coverage modelcan be functional code coverage model.

According to one or more embodiments of the present invention, at block306, after the test execution engine 108 executes the generated tests,the fingerprint generator 204 generates fingerprints corresponding tothe executed tests. For example, each fingerprint uniquely identifiesthe code path traversed during execution of a corresponding regressiontest. In some exemplary embodiments of the present invention, thefingerprint generation algorithm employed by the fingerprint generator204 generates a fingerprint that identifies not only the breakpointsencountered during traversal of a code path and the number of times eachsuch breakpoint is encountered, but also the order in which theencounters occur. Thus, if execution of two different regression testsresults in code paths that encounter the same breakpoints the samenumber of times but in different orders, the respective fingerprintgenerated for each regression test will uniquely identify the particularorder in which breakpoint encounters occur for that regression test.

At block 308, the test case analyzer 218 compares the fingerprintsgenerated at block 306 with a plurality of fingerprints stored in thefingerprints repository 206. The test case analyzer 218 attempts to findexact matches. As a non-limiting example, if the fingerprint generator204 employs a string-based algorithm and generates the fingerprint<ABABCDCDE> for a corresponding regression test, at block 308 the testcase analyzer 218 determines whether there are any <ABABCDCDE>fingerprints in the fingerprints repository 206. It should be noted,each element of the string <ABABCDCDE> identifies a correspondingbreakpoint that is encountered; the number of times that the sameelement appears in the string indicates the number of times thecorresponding breakpoint is encountered; and the ordering of theelements in the string indicates the order in which the breakpoints areencountered. Once the test case analyzer 218 identifies matchingfingerprints, it also identifies corresponding test cases stored in thetest repository 202 based on the identified fingerprint information. Itshould be noted that in other embodiments of the invention, thefingerprint is represented using other format, such as a hash key, orany other format.

If the test case analyzer 218 finds no matching fingerprints (decisionblock 310, No branch), the disclosed method ends at block 314.Responsive to finding one or more matching fingerprints (decision block310, Yes branch), at block 312, the test case analyzer 218 removes theredundant test cases associated with the matching fingerprint from thetest repository 202. In other words, if one or more of older test caseis associated with a fingerprint that matches the fingerprint of one ofthe newer generated CTD tests, then the older case can be removed fromthe test repository 202. This reduction of redundant test casesadvantageously alleviates maintenance requirements on the testinfrastructure as older test cases are gradually cycled out.

However, even such a reduced set of tests cannot be used on a “live”environment 100, such as in an active data center that is being used byconsumers/customers. The live environment is not a “clean” environmentas discussed earlier, and in one or more embodiments of the presentinvention, the live environment is one in which soft failures are beingexperienced. Hence, to address the technical challenges, in one or moreembodiments of the present invention, the reduced set of tests isfurther reduced so that a minimal set of test cases can be used to testthe live environment 100. This minimal set is even more reduced than atypical pairwise reduction set. In an environment that experiences softfailures, embodiments of the present invention treat all services asbeing in a fragile state. Hence, embodiments of the present inventionuse the minimal set of tests, instead of the pairwise tests, tofacilitate identifying the fault(s) that are causing the soft failuresand repairing the fault(s) instead of further stressing the environment100 and causing it to fail completely (crashing).

The pairwise tests have an overlap between the various attributes tocover as much of the test space as possible in the fewest set of tests.In other words, the pairwise tests that are generated (at block 314)include tests that have an overlap between attributes being tested so asto maximize test space coverage. Instead, when diagnosing the softfailures, embodiments of the present invention facilitate using the mostdisjoint set of tests to cover the edges of the test space first beforenarrowing in on the fault(s) in the environment 100. The minimal set oftests provides such disjoint set of tests. This is analogous to a doctorexamining a patient to identify likely sources for their ailments.

FIG. 4 depicts a flowchart of a method 400 for generating a minimal setof tests for diagnosing portions of a system that are causing softfailures when executing a SUT according to one or more embodiments ofthe present invention. The method 400 includes generatingattribute-value pairwise tests for the SUT 214, at block 402. Thepairwise tests can be generated using CTD in one or more embodiments ofthe present invention. Any other technique can be used for generatingthe pairwise tests. In one or more embodiments of the present invention,generating the tests includes selecting a reduced set of the pairwisetests to provide maximum test coverage for the SUT 214.

The attribute-value pairs that are used by the reduced set of testsinclude overlap. For example, a first test can test attributes A-B, asecond test can test attributes B-C, a third test can test attributesC-D, etc. Here, A, B, C, and D, are attributes of the SUT 214.

The method 400 further includes identifying overlap/redundancies in theattributes being tested, at block 404. In one or more embodiments of thepresent invention, the identified tests are marked as redundant tests.In one or more embodiments of the present invention, an orthogonalCartesian selection using abatement and pair correlation can be used toidentify the redundant tests from the pairwise tests that are generatedfor testing the entire test space. For example, in the above example,the second test that tests attributes B-C is identified as beingredundant because the first and the third tests facilitate testing theattributes A, B, C, and D. Accordingly, the method 400 includesidentifying tests in the reduced set of tests that exercise the sameattributes of the SUT 214. If two tests, a first test and a second test,both, exercise at least one common attribute, one of the two tests ismarked as a redundant test at block 410. Marking the test as redundantcan include including a unique identifier of the test, (for example, anindex, a hash etc.) in a list of redundant tests. Alternatively, a listof non-redundant tests can be maintained in a similar manner.

In one or more embodiments of the present invention, prior to marking atest as a redundant test, the method 400 further includes determining ifthere are any restrictions that prevent marking the test as a redundanttest, at block 406. For example, a restriction can exist for testing theSUT 214 such that a particular test has to be executed for anotherparticular test to be executed. For example, in a scenario with theabove set of tests may be that the third test (for attributes C-D) canonly be executed if the second test (for attributes B-C) is executed.Accordingly, in this case, the second test cannot be marked as aredundant test. The restriction can arise, for example, based on a stateof the SUT 214 after executing the second test that may be aprerequisite for executing the third test. It is understood that theabove is just one example, and that in other embodiments of the presentinvention, other types of restrictions can exist.

Accordingly, referring to the flowchart, if a restriction is determinedwith a test that was identified as a redundant test, that test is notmarked as a redundant test, at block 408. Alternatively, if it isdetermined that a restriction does not exist, the test is marked as aredundant test, at block 410.

The method 400 includes minimizing the reduced set of test cases furtherby eliminating the redundant tests, at block 412. Minimizing the reducedset of test cases includes generating another set of tests that includesall of the tests from the reduced set of tests except the tests that aremarked as the redundant tests. The method further includes sending theminimal set of tests to the SUT 214 for execution, at block 414. The SUT214 executes the minimal set of tests.

FIG. 5 depicts a flowchart of a method 500 for executing the minimal setof tests for the SUT to detect soft failures according to one or moreembodiments of the present invention. In one or more embodiments of thepresent invention, the test execution engine 108 executes the minimaltests on the SUT 214, at block 502. The test execution engine 108monitors the results of the execution, at block 504.

If the test execution engine 108 detects that execution of a test fromthe minimal set of tests deviates from an expected set of parameters(“YES” at block 506), the test execution engine 108 identifies a codepath associated with the test, at blocks 506 and 508. For example, thedeviation can be a different amount of time required for executing thetest compared to a predetermined time associated with the test. Thepredetermined time that is associated with the test can be based on aduration it takes to execute that test in a clean system that can bemaintained by the developer of the SUT 214, in one or more examples.

According to one or more embodiments of the present invention, thefingerprint generator 204 keeps track of an execution time of each test.For example, the fingerprint generator 204 measures the execution timeof each test in a “clean” environment 100. Here, the clean environmentrepresents a known system in which the soft failures are notexperienced, for example, a computer system that is maintained by thedeveloper of the SUT 214. It is understood that in other embodiments ofthe present invention, the execution time can be tracked by some othermodule than the fingerprint generator 204.

In environments where soft failures are experienced, timing window basederrors can be used to detect the cause of the soft failures according toone or more embodiments of the present invention. A timing window is asequence in time in which multiple events are occurring simultaneously.Recreating a specific timing window to diagnose an error can beextremely difficult, if not impossible, when the events that occurredcreate or exist in the execution environment 100 with a lot of entropy.In some cases, investigating a given error directly alters the executiontime of various events. This can obscure the root cause of the problemor create additional problems that do not generally occur in theenvironment 100, such as resource contention. By monitoring theexecution time of the tests, particularly the minimal set of tests thatexercise disjoint code paths of the SUT 214, one or more embodiments ofthe present invention facilitate identifying specific code paths thatcause the soft failure in the environment 100. The specific code paths,which are accordingly identified, can be further exercised to diagnosethe soft failure(s) and to possibly determine a solution(s) to the softfailure(s).

If a given test with a known execution time in a healthy/cleanenvironment runs slower or faster (than the known execution time) in theactive environment 100, the portions of the SUT 214 exercised by thetest can be identified. For example, the exercised portion can beidentified using a code flow technology such as break pointfingerprints. If the test fails during the diagnosis phase, inverse CTDcan be employed to further define the scope of the detected error. Theset of errors and timing deltas that are identified can further identifysuspicious or portions of the SUT 214 that may be causing the softfailure(s).

Other deviations, than those in execution time, can also be monitored bythe test execution engine. Such other deviations include a differentvalue of the attribute being exercised by the test after execution ofthe test is complete. Alternatively, or in addition, deviations caninclude a different memory location being used during execution of thetest compared to a memory location used by the test in the clean system.It is understood that other types of deviation can be detected in otherembodiments of the present invention and the above provided examples arejust a possible subset of deviations.

Once the deviation is detected, in one or more embodiments of thepresent invention, the test execution engine 108 performs an analysis toidentify a particular code path (“code path”) that is executed by thetest that resulted in the deviation. The sequence in which statements orevents in the test are performed can depend on particular valuesassociated with particular variables. As part of this analysis, the testexecution engine 108 determines under what specific circumstancesprogram control of the SUT 214 flows through the code path. For example,the test execution engine 108 may determine the last decision branch inthe SUT 214 that was taken to drive the code path. Such a decisionbranch may be associated with a particular breakpoint, as discussedbelow.

At block 510 of the method 500, the test execution engine 108 determineswhich breakpoints are encountered during execution of the code path andthe number of times each such breakpoint is encountered as well as,potentially, an order in which the breakpoints are encountered. Inaddition, at block 510, the test execution engine 108 may determine thefingerprint for the code path based at least in part on the identifiedexecution code path and the assigned breakpoint values.

The fingerprint of the identified code path is stored in one or moreexamples. Further, the stored code paths can be communicated to thedevelopment/testing team of the SUT 214 to analyze the code paths anddetermine cause/solution for the soft failures experienced by the livesystem when executing the minimal set of tests. The method can furtherinclude generating and sending tests to further exercise the identifiedcode path in the live environment 100 as well as the clean environment,at block 512. Generating such tests can include selecting, from thereduced set of tests (FIG. 3 ), a subset of tests that are associatedwith the identified fingerprint.

In one or more embodiments of the present invention, the identified codepath is not executed in the environment 100. For example, if and whenthe SUT 214, during execution, reaches the identified code path, the SUT214 can terminate execution, instead of causing the soft failure.Alternatively, or in addition, in one or more embodiments of the presentinvention, the SUT 214 may prompt a user for instructions upon reachingthe identified code path, and proceed as per the user instructions. Inone embodiment of the present invention, the user's feedback mayindicate instructions/alternative course of actions with respect toaverting the detected code path. The provided instructions may includebut are not limited to an alternative code path for the SUT 214 to use.

If the test execution of all the tests in the minimal set of tests doesnot deviate from the execution on the clean system, that is, theexecution is according to respective set of predetermined parameters(“NO” at block 506), the test execution engine 108 requests a differentminimal set of tests to be generated, at block 514. The method 500 isthen repeated using the different minimal set of tests. For example, thedifferent minimal set of tests can include tests that were eliminated inthe earlier iteration of selecting the minimal set of tests. Forexample, tests that were marked as redundant are included in thedifferent minimal set of tests being generated. In one or moreembodiments of the present invention, a predetermined number ofrepetitions are performed. Alternatively, or in addition, if a differentminimal set of tests cannot be generated (all options exhausted), themethod 500 is not repeated.

Embodiments of the present invention accordingly address the technicalchallenges to identify and repair causes of soft failures in an activeenvironment, where the SUT 214 is being used as a live system.Embodiments of the present invention can also facilitate restoring thehealth of the SUT 214 in case of such soft failures. If such diagnosisand repair is done incorrectly or too slowly, the SUT 214 can faceadditional failures and in some cases a complete shutdown instead. Suchadditional failures can cause customers/users of the SUT 214 toexperience service outages or loss of data, which can adversely affectrevenues and/or reputation of a client or company that is providing theSUT 214. By using the minimal set of tests as described herein,embodiments of the present invention facilitate diagnosing, withoutcausing resource contention, areas of the live environment 100 that maybe causing the soft failures.

In one or more embodiments of the present invention, once the affectedareas are identified, the coverage analysis tool 104 calculates codecoverage using flow technologies such as fingerprinting, e.g. using thebreak point fingerprints. In one or more embodiments of the presentinvention the coverage analysis tool 104 calculates the code coverage bycomparing the flows exercised by the minima set of tests against adatabase of existing predetermined flows for the SUT 214. For example,the developers of the SUT 214 identify the predetermined flows in theclean environment.

The comparison of the code paths exercised by the minimal set of testsand the predetermined code paths facilitates identifying specific linesof code in the SUT 214, where the specific lines of code contribute tothe symptoms/cause of the soft failure. For example, the comparison ofthe code paths can include determining which branch-points and/orbreakpoints in the SUT 214 are exercised by the minimal set of tests.The coverage analysis tool 104 can identify the specific lines/portionsof the code of the SUT 214 that are exercised by the minimal set oftests by identifying the branch-points and/or the breakpoints.

The identified portions of the code are communicated to the developers.For example, the filenames, line numbers, and other identifiersassociated with the portions of the code are provided to the developers.The developers can develop a patch or strategy to alleviate the symptomsof the ailing SUT 214 and restore its health in the live environment 100based on the identified code portions. In one or more embodiments of thepresent invention, the developers can update the SUT 214 to preventexecution of the identified portions of the code. For example, apatch/update for the SUT 214 can cause the SUT 214 to stop execution andprompt a user to select an alternative execution path upon reaching thecode path that is marked by the minimal set of test cases.Alternatively, the SUT 214 can be updated to automatically select analternative code path that is not marked as causing a soft failure. Forexample, if a code path of the SUT 214 originally included allocating amemory buffer of a particular size, and if that code path is marked asleading to a soft failure, the updated SUT 214 can prevent execution ofthe code path altogether. Alternatively, the updated SUT 214 can includean alternative code path that first checks that the requested buffersize is available and only if sufficient memory is available, the memoryallocation is performed. It is understood that the above is just one ofseveral possible examples of updating the SUT 214 to prevent/bypass amarked code path.

In one or more embodiments of the present invention the developers candiagnose the cause of the soft failure by maximizing a number of flowsto maximize the coverage of tests in the identified portion of code. Asnoted herein, to minimize interruption to the live environment 100,ideally, it is beneficial to execute the smallest possible number oftests. Accordingly, a second minimal set of tests is generated, which isdirected only to the identified portion of the SUT 214.

FIG. 6 depicts a flowchart of a method 600 for exercising a specificportion of an SUT according to one or more embodiments of the presentinvention. The method 600 includes identifying a code path that exhibitsthe soft failure in the live environment 100, at block 602. The codepath is identified using the minimal set of tests as described herein,in one or more embodiments of the present invention. Alternatively, orin addition, the code path can be identified by receiving an input froma developer/personnel, where the input is indicative of the code paththat is to be exercised.

The method 600 further includes identifying pairwise tests 202 that areassociated with the code path, at block 604. The pairwise tests areidentified using the fingerprints of the tests. For example, thefingerprint of the code path is compared with those of pairwise tests202. If the fingerprint of the code path exists in the fingerprint of atest, that test is identified as being associated with the code path.The fingerprint of the code path is included in that of the test if thetest exercises that code path. The identified tests are included in aset of selected tests, at block 606. In one or more embodiments of thepresent invention, a test is included in the set of selected tests byincluding a unique identifier of the test in a list of tests, whichrepresents the set of selected tests.

The set of selected tests is further reduced to generate a reduced setof tests for the identified portion of the SUT 214, at block 608. In oneor more examples, the reduction is performed if the number of tests inthe set of selected tests is above a predetermined threshold. Suchselected tests are executed by the test execution engine 108 and theresults are monitored to diagnose a cause of the soft failure. Further,in one or more embodiments of the present invention a solution to avoidthe soft failure can also be determined and the SUT 214 modifiedaccording to the solution.

Additionally, the extra diagnostic and logistical information collectedfrom testing SUT 214 is used to enhance existing and new systems of thesame type as the SUT 214 to immunize those systems from the samesymptoms. This is analogous to a doctor finding a cure and vaccinatingothers to reduce or eradicate an illness.

Turning now to FIG. 7 , a computer system 700 is generally shown inaccordance with an embodiment. The computer system 700 can be anelectronic, computer framework comprising and/or employing any numberand combination of computing devices and networks utilizing variouscommunication technologies, as described herein. The computer system 700can be easily scalable, extensible, and modular, with the ability tochange to different services or reconfigure some features independentlyof others. The computer system 700 may be, for example, a server,desktop computer, laptop computer, tablet computer, or smartphone. Insome examples, computer system 700 may be a cloud computing node.Computer system 700 may be described in the general context of computersystem executable instructions, such as program modules, being executedby a computer system. Generally, program modules may include routines,programs, objects, components, logic, data structures, and so on thatperform particular tasks or implement particular abstract data types.Computer system 700 may be practiced in distributed cloud computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed cloudcomputing environment, program modules may be located in both local andremote computer system storage media including memory storage devices.

As shown in FIG. 7 , the computer system 700 has one or more centralprocessing units (CPU(s)) 701 a, 701 b, 701 c, etc. (collectively orgenerically referred to as processor(s) 701). The processors 701 can bea single-core processor, multi-core processor, computing cluster, or anynumber of other configurations. The processors 701, also referred to asprocessing circuits, are coupled via a system bus 702 to a system memory703 and various other components. The system memory 703 can include aread only memory (ROM) 704 and a random access memory (RAM) 705. The ROM704 is coupled to the system bus 702 and may include a basicinput/output system (BIOS), which controls certain basic functions ofthe computer system 700. The RAM is read-write memory coupled to thesystem bus 702 for use by the processors 701. The system memory 703provides temporary memory space for operations of said instructionsduring operation. The system memory 703 can include random access memory(RAM), read only memory, flash memory, or any other suitable memorysystems.

The computer system 700 comprises an input/output (I/O) adapter 706 anda communications adapter 707 coupled to the system bus 702. The I/Oadapter 706 may be a small computer system interface (SCSI) adapter thatcommunicates with a hard disk 708 and/or any other similar component.The I/O adapter 706 and the hard disk 708 are collectively referred toherein as a mass storage 710.

Software 711 for execution on the computer system 700 may be stored inthe mass storage 710. The mass storage 710 is an example of a tangiblestorage medium readable by the processors 701, where the software 711 isstored as instructions for execution by the processors 701 to cause thecomputer system 700 to operate, such as is described herein below withrespect to the various Figures. Examples of computer program product andthe execution of such instruction is discussed herein in more detail.The communications adapter 707 interconnects the system bus 702 with anetwork 712, which may be an outside network, enabling the computersystem 700 to communicate with other such systems. In one embodiment, aportion of the system memory 703 and the mass storage 710 collectivelystore an operating system, which may be any appropriate operatingsystem, such as the z/OS or AIX operating system from IBM Corporation,to coordinate the functions of the various components shown in FIG. 7 .

Additional input/output devices are shown as connected to the system bus702 via a display adapter 715 and an interface adapter 716 and. In oneembodiment, the adapters 706, 707, 715, and 716 may be connected to oneor more I/O buses that are connected to the system bus 702 via anintermediate bus bridge (not shown). A display 719 (e.g., a screen or adisplay monitor) is connected to the system bus 702 by a display adapter715, which may include a graphics controller to improve the performanceof graphics intensive applications and a video controller. A keyboard721, a mouse 722, a speaker 723, etc. can be interconnected to thesystem bus 702 via the interface adapter 716, which may include, forexample, a Super I/O chip integrating multiple device adapters into asingle integrated circuit. Suitable I/O buses for connecting peripheraldevices such as hard disk controllers, network adapters, and graphicsadapters typically include common protocols, such as the PeripheralComponent Interconnect (PCI). Thus, as configured in FIG. 7 , thecomputer system 700 includes processing capability in the form of theprocessors 701, and, storage capability including the system memory 703and the mass storage 710, input means such as the keyboard 721 and themouse 722, and output capability including the speaker 723 and thedisplay 719.

In some embodiments, the communications adapter 707 can transmit datausing any suitable interface or protocol, such as the internet smallcomputer system interface, among others. The network 712 may be acellular network, a radio network, a wide area network (WAN), a localarea network (LAN), or the Internet, among others. An external computingdevice may connect to the computer system 700 through the network 712.In some examples, an external computing device may be an externalwebserver or a cloud computing node.

It is to be understood that the block diagram of FIG. 7 is not intendedto indicate that the computer system 700 is to include all of thecomponents shown in FIG. 7 . Rather, the computer system 700 can includeany appropriate fewer or additional components not illustrated in FIG. 7(e.g., additional memory components, embedded controllers, modules,additional network interfaces, etc.). Further, the embodiments describedherein with respect to computer system 700 may be implemented with anyappropriate logic, wherein the logic, as referred to herein, can includeany suitable hardware (e.g., a processor, an embedded controller, or anapplication specific integrated circuit, among others), software (e.g.,an application, among others), firmware, or any suitable combination ofhardware, software, and firmware, in various embodiments. In one or moreembodiments of the present invention, the computer system 700 can be theenvironment 100 with the SUT being a computer program or a hardwarecomponent being used by the computer system 700. In one or moreembodiments of the present invention, the computer system 700 can be theSUT 214, which is part of a server cluster.

The present invention may be a system, a method, and/or a computerprogram product at any possible technical detail level of integration.The computer program product may include a computer-readable storagemedium (or media) having computer-readable program instructions thereonfor causing a processor to carry out aspects of the present invention.

The computer-readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer-readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer-readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer-readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission medium (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer-readable program instructions described herein can bedownloaded to respective computing/processing devices from acomputer-readable storage medium or to an external computer or externalstorage device via a network, for example, the Internet, a local areanetwork, a wide area network and/or a wireless network. The network maycomprise copper transmission cables, optical transmission fibers,wireless transmission, routers, firewalls, switches, gateway computersand/or edge servers. A network adapter card or network interface in eachcomputing/processing device receives computer-readable programinstructions from the network and forwards the computer-readable programinstructions for storage in a computer-readable storage medium withinthe respective computing/processing device.

Computer-readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine-dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source-code or object code written in any combination of one ormore programming languages, including an object-oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer-readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some embodiments, electronic circuitry including,for example, programmable logic circuitry, field-programmable gatearrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer-readable program instruction by utilizing state information ofthe computer-readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer-readable program instructions.

These computer-readable program instructions may be provided to aprocessor of a general-purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer-readable program instructionsmay also be stored in a computer-readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that thecomputer-readable storage medium having instructions stored thereincomprises an article of manufacture including instructions whichimplement aspects of the function/act specified in the flowchart and/orblock diagram block or blocks.

The computer-readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other devices to produce acomputer-implemented process, such that the instructions which executeon the computer, other programmable apparatus, or other device implementthe functions/acts specified in the flowchart and/or block diagram blockor blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

The descriptions of the various embodiments of the present inventionhave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdescribed herein.

Various embodiments of the invention are described herein with referenceto the related drawings. Alternative embodiments of the invention can bedevised without departing from the scope of this invention. Variousconnections and positional relationships (e.g., over, below, adjacent,etc.) are set forth between elements in the following description and inthe drawings. These connections and/or positional relationships, unlessspecified otherwise, can be direct or indirect, and the presentinvention is not intended to be limiting in this respect. Accordingly, acoupling of entities can refer to either a direct or an indirectcoupling, and a positional relationship between entities can be a director indirect positional relationship. Moreover, the various tasks andprocess steps described herein can be incorporated into a morecomprehensive procedure or process having additional steps orfunctionality not described in detail herein.

The following definitions and abbreviations are to be used for theinterpretation of the claims and the specification. As used herein, theterms “comprises,” “comprising,” “includes,” “including,” “has,”“having,” “contains” or “containing,” or any other variation thereof,are intended to cover a non-exclusive inclusion. For example, acomposition, a mixture, process, method, article, or apparatus thatcomprises a list of elements is not necessarily limited to only thoseelements but can include other elements not expressly listed or inherentto such composition, mixture, process, method, article, or apparatus.

Additionally, the term “exemplary” is used herein to mean “serving as anexample, instance or illustration.” Any embodiment or design describedherein as “exemplary” is not necessarily to be construed as preferred oradvantageous over other embodiments or designs. The terms “at least one”and “one or more” may be understood to include any integer numbergreater than or equal to one, i.e. one, two, three, four, etc. The terms“a plurality” may be understood to include any integer number greaterthan or equal to two, i.e. two, three, four, five, etc. The term“connection” may include both an indirect “connection” and a direct“connection.”

The terms “about,” “substantially,” “approximately,” and variationsthereof, are intended to include the degree of error associated withmeasurement of the particular quantity based upon the equipmentavailable at the time of filing the application. For example, “about”can include a range of ±8% or 5%, or 2% of a given value.

For the sake of brevity, conventional techniques related to making andusing aspects of the invention may or may not be described in detailherein. In particular, various aspects of computing systems and specificcomputer programs to implement the various technical features describedherein are well known. Accordingly, in the interest of brevity, manyconventional implementation details are only mentioned briefly herein orare omitted entirely without providing the well-known system and/orprocess details.

What is claimed is:
 1. A method for testing a system under test (SUT) inan active environment, the method comprising: receiving, by a testingsystem, a code path of the SUT that is marked to cause a soft failure inthe active environment, wherein the soft failure occurs in the activeenvironment during execution of the SUT based at least on a parameter ofthe active environment; generating, by the testing system, a pluralityof tests for testing the SUT, the plurality of tests generated based ona coverage model of the SUT, wherein the coverage model comprises aplurality of attributes; selecting, by the testing system, from theplurality of tests, a set of tests that are associated with the codepath; reducing the set of tests in response to a number of tests in theset of tests exceeding a predetermined threshold, wherein the reducingthe set of tests comprises an orthogonal Cartesian selection usingabatement and pair correlation; executing, by the testing system, onlythe reduced set of tests that are selected on the SUT to analyze a causeof the soft failure; and in response to a failure of at least apredetermined number of tests from the reduced set of tests identifyingthe parameter of the active environment causing the soft failure,issuing a patch that comprises an updated source code of the SUT toalleviate the soft failure during a subsequent execution of the SUT inthe active environment by determining that one or more conditionsassociated with the parameter causing the soft failure do not exist inthe active environment at time of execution of the code path in thesubsequent execution, and selecting an alternative execution pathinstead of the code path in response to determining that the one or moreconditions exist, wherein the alternative execution path is not markedas causing soft failures, wherein: selecting the set of tests comprisesidentifying that a test from the plurality of tests is associated withthe code path using fingerprints of the code path, and the fingerprintsare generated by a fingerprint generator to identify for each testbreakpoints encountered during traversal of code paths, numbers of timeseach breakpoint is encountered and an order in which encountering thebreakpoints occurs.
 2. The method of claim 1, wherein each of theplurality of attributes has a set of possible values and wherein thecoverage model defines possible combinations of values of the attributesas covered by the plurality of tests.
 3. The method of claim 1, furthercomprising updating the SUT to bypass execution of the code path.
 4. Themethod of claim 1, wherein the plurality of tests is generated usingcombinatorial test design (CTD).
 5. The method of claim 1, wherein thecondition that causes the soft failure comprises allocating a memorybuffer of a size larger than a predetermined value.
 6. The method ofclaim 1, wherein the updating the SUT to alleviate the soft failurecomprises editing source code of the SUT to select the alternativeexecution path in response to the condition that causes the soft failurein the code path.
 7. A system comprising: a memory device; and one ormore processing units coupled with the memory device, the one or moreprocessing units configured to perform a method comprising: receiving acode path of a system under test (SUT) that is being executed in anactive environment that marked to cause a soft failure in the activeenvironment, wherein the soft failure occurs in the active environmentduring execution of the SUT based at least on a parameter of the activeenvironment; generating a plurality of tests for testing the SUT, theplurality of tests is generated based on a coverage model of the SUT,wherein the coverage model comprises a plurality of attributes;selecting from the plurality of tests, a set of tests that areassociated with the code path; reducing the set of tests in response toa number of tests in the set of tests exceeding a predeterminedthreshold, wherein the reducing the set of tests comprises an orthogonalCartesian selection using abatement and pair correlation; executing onlythe reduced set of tests that are selected on the SUT to analyze a causeof the soft failure; and in response to a failure of at least apredetermined number of tests from the reduced set of tests identifyingthe parameter of the active environment causing the soft failure,issuing a patch that comprises an updated source code of the SUT toalleviate the soft failure during a subsequent execution of the SUT inthe active environment by determining that one or more conditionsassociated with the parameter causing the soft failure do not exist inthe active environment at time of execution of the code path in thesubsequent execution, and selecting an alternative execution pathinstead of the code path in response to determining that the one or moreconditions exist, wherein the alternative execution path is not markedas causing soft failures, wherein: selecting the set of tests comprisesidentifying that a test from the plurality of tests is associated withthe code path using fingerprints of the code path, and the fingerprintsare generated by a fingerprint generator to identify for each testbreakpoints encountered during traversal of code paths, numbers of timeseach breakpoint is encountered and an order in which encountering thebreakpoints occurs.
 8. The system of claim 7, wherein each of theplurality of attributes has a set of possible values and wherein thecoverage model defines possible combinations of values of the attributesas covered by the plurality of tests.
 9. The system of claim 7, whereinthe method further comprises updating the SUT to bypass execution of thecode path.
 10. The system of claim 7, wherein the plurality of tests isgenerated using combinatorial test design (CTD).
 11. The system of claim7, wherein the condition that causes the soft failure comprisesallocating a memory buffer of a size larger than a predetermined value.12. The system of claim 7, wherein the updating the SUT to alleviate thesoft failure comprises editing source code of the SUT to select thealternative execution path in response to the condition that causes thesoft failure in the code path.
 13. A computer program product comprisinga computer-readable storage medium having computer-executableinstructions stored thereupon, which when executed by a processor causethe processor to perform for testing a system under test (SUT) in anactive environment, the method comprising: receiving a code path of theSUT that is marked to cause a soft failure in the active environment,wherein the soft failure occurs in the active environment duringexecution of the SUT based at least on a parameter of the activeenvironment; generating a plurality of tests for testing the SUT, theplurality of tests is generated based on a coverage model of the SUT,wherein the coverage model comprises a plurality of attributes;selecting from the plurality of tests, a set of tests that areassociated with the code path; reducing the set of tests in response toa number of tests in the set of tests exceeding a predeterminedthreshold, wherein the reducing the set of tests comprises an orthogonalCartesian selection using abatement and pair correlation; executing onlythe reduced set of tests that are selected on the SUT to analyze a causeof the soft failure; and in response to a failure of at least apredetermined number of tests from the reduced set of tests identifyingthe parameter of the active environment causing the soft failure,issuing a patch that comprises an updated source code of the SUT toalleviate the soft failure during a subsequent execution of the SUT inthe active environment by determining that one or more conditionsassociated with the parameter causing the soft failure do not exist inthe active environment at time of execution of the code path in thesubsequent execution, and selecting an alternative execution pathinstead of the code path in response to determining that the one or moreconditions exist, wherein the alternative execution path is not markedas causing soft failures, wherein: selecting the set of tests comprisesidentifying that a test from the plurality of tests is associated withthe code path using fingerprints of the code path, and the fingerprintsare generated by a fingerprint generator to identify for each testbreakpoints encountered during traversal of code paths, numbers of timeseach breakpoint is encountered and an order in which encountering thebreakpoints occurs.
 14. The computer program product of claim 13,wherein each of the plurality of attributes has a set of possible valuesand wherein the coverage model defines possible combinations of valuesof the attributes as covered by the plurality of tests.
 15. The computerprogram product of claim 13, wherein the method further comprisesupdating the SUT to bypass execution of the code path.
 16. The computerprogram product of claim 13, wherein the plurality of tests is generatedusing combinatorial test design (CTD).